A goal of the Third (3rd) Generation Partnership Project (3GPP) Long Term Evolution (LTE) program is to develop new technology, new architecture, and new methods in new LTE settings and configurations. These features are being developed to provide improved spectral efficiency, reduced latency, and better utilization of the radio resources. These features are intended to provide faster user experiences, richer applications, and improved services, with less cost.
LTE is a Packet Switched (PS)-only radio technology. It is desirable to support backwards mobility with legacy Global System for Mobile Communications (GSM). For inter-working with legacy Circuit Switched (CS) networks, such as GSM, it was expected that IP Multimedia Core Network Subsystem (IMS) networks would be deployed. Specifically, Voice Call Continuity (VCC) was expected to be the technique used for handing over voice calls from LTE PS networks, using Voice over Internet Protocol (VoIP) techniques, to legacy CS networks. It would be desirable to de-couple IMS deployments from LTE deployments. In other words, it would be desirable to initially use the currently deployed CS infrastructure for voice calls, while deploying LTE for high-speed PS services only. For this reason, it would be desirable for LTE to allow a multi-mode wireless transmit/receive unit (WTRU), such as with LTE and GSM and/or Wideband Code Division Multiple Access (WCDMA), use the LTE network for high-speed PS data traffic while reverting to legacy CS network for voice traffic, without necessarily using any IMS features such as VCC.
When a WTRU attaches to the Evolved Packet System (EPS) over the E-UTRAN network, the Non Access Stratum (NAS) layer Attach message may include a CS fallback indicator to indicate to the network the need to attach the WTRU in the CS domain as well. The Mobility Management Entity (MME) may then perform the attachment to the CS domain on behalf of the WTRU, before indicating that the process completed via the Attach Accept message, as shown in FIG. 1. The Attach procedure for the CS fallback in EPS may be realized based on a combined General Packet Radio Service (GPRS)/International Mobile Subscriber Identifier (IMSI) Attach procedure as specified in the 3GPP standard TS 23.060.
FIG. 1 is a flow diagram of a method 100 for performing an Attach procedure. In the method 100, messages are exchanged between a WTRU 102, an MME 104, a mobile switching center/visitor location register (MSC/VLR) 106, and a home subscriber server (HSS) 108. The WTRU 102 initiates the Attach procedure by transmitting an Attach Request message, including parameters as specified in 3GPP standard TS 23.401 and a CS fallback indicator, to the MME 104 (step 110). The CS fallback indicator indicates that the WTRU 102 is capable of using CS fallback and configured to use CS fallback.
The EPS Attach procedure is performed as specified in 3GPP standard TS 23.401 (step 112). The VLR 106 is updated according to the combined GPRS/IMSI Attach procedure in 3GPP standard TS 23.060 if the Attach Request message includes a Combined Update indicator (step 114). The VLR number is derived from the Tracking Area Identity (TAT). The MME 104 starts the location update procedure towards the new MS C/VLR upon receiving the first Insert Subscriber Data message from the HSS 108. This operation marks the WTRU 102 as EPS-attached in the VLR 106.
The MME 104 sends a Location Update Request message, such as a new Location Area Identity (LAI), IMSI, MME address, or Location Update Type, to the VLR 106 (step 116). A new LAI is determined in the MME 104 based on a mapping from the Tracking Area (TA). A mapped LAI may be to either a GSM EDGE Radio Access Network (GERAN) or a UMTS Terrestrial Radio Access Network (UTRAN).
The VLR 106 creates an association with the MME 104 by storing the MME address (step 118). The VLR 106 performs a location update procedure in the CS domain (step 120). The VLR 106 responds to the MME 104 with a Location Update Accept message, such as a VLR Temporary Mobile Subscriber Identity (TMSI) (step 122). The MME 104 sends an Attach Accept message, including parameters as specified in 3GPP standard TS 23.401, a Location Area Identity (LAI), and a VLR TMSI (if allocated), to the WTRU (step 124). The existence of a LAI (and a VLR TMSI, if allocated) indicates a successful attachment to the CS domain.
FIG. 2 is a flow diagram of a method 200 for a WTRU terminating a call while in Idle mode. In the method 200, messages are exchanged between a WTRU 202, an eNB 204, a MME 206, a radio network controller (RNC) or base station controller (BSC) 208, a MSC/VLR 210, a HSS 212, and a gateway mobile switching center (GMSC) 214.
The method 200 begins with the GMSC 214 receives an initial address message (IAM; step 220). The GMSC 214 retrieves the routing information of the terminating WTRU by using the Send Routing Info (SRI) procedures (step 222). The GMSC 214 sends the IAM to the MSC 210 on the terminating side (step 224).
The MME 206 receives a paging (IMSI, VLR TMSI, or Location Information) message from the MSC 210 over a SGs interface (step 226). The TMSI (or IMSI) received from the MSC 210 is used by the MME 206 to find the S-TMSI, which is used as the paging address on the radio interface. If the location information is reliably known by the MME 206 (i.e., the MME stores the list of TAs), the MME 206 pages the WTRU 202 in all the TAs. If the MME 206 does not have a stored TA list for the WTRU 202, the MME 206 should use the location information received from the MSC to page the WTRU. If pre-paging is deployed, this procedure takes place before step 224, immediately after the MSC 210 receives the MAP_PRN message from the HSS 212.
The MME 206 sends a paging message to each eNB 204 (step 228). The paging message includes a suitable WTRU identity (i.e., S-TMSI or IMSI) and a core network (CN) domain indicator that indicates which domain (CS or PS) initiated the paging message. In this case, the domain indicator is set to “CS” by the MME 206. The eNB 204 pages the WTRU 202 (step 230), and the paging message contains a suitable WTRU identity (i.e., S-TMSI or IMSI) and a CN domain indicator.
The WTRU 202 establishes an RRC connection and sends an Extended Service Request (CS fallback indicator) to the MME 206 (step 232). The WTRU 202 indicates its S-TMSI in the RRC signaling. The Extended Service Request message is encapsulated in RRC and 51 AP messages. The CS fallback indicator indicates to the MME 206 that CS fallback for the WTRU 206 is required. The MME 206 sends 51 AP: Initial WTRU Context Setup (including WTRU capabilities, CS fallback indicator, and other parameters) to indicate the eNB 204 to move the WTRU 202 to UTRAN/GERAN (step 234).
For the next action, there are two options, the choice depending on whether the target RAT has PS handover (HO) capability or not. If the target RAT has PS HO capability, then upon receipt of the Initial WTRU Context Setup message with a CS fallback indicator, the eNB 204 may optionally solicit measurement reports from the WTRU 202 to determine the target cell to which PS handover will be performed (step 236). A PS handover is then performed and as part of the PS handover, the WTRU 202 receives a HO from E-UTRAN Command that may contain a CS fallback indicator, which indicates to the WTRU 202 that the handover was triggered due to a CS fallback request. If the HO from E-UTRAN Command contains a CS fallback indicator and the WTRU 202 fails to establish a connection to the target RAT, then the WTRU 202 considers that the CS fallback has failed.
If the target RAT has no PS HO capability, then upon receipt of the Initial WTRU Context Setup message with a CS fallback indicator, the eNB 204 may optionally solicit measurement reports from the WTRU 202 to determine the target cell to redirect the WTRU 202 to (step 236). After that, the eNB 204 releases the RRC Connection with redirection information to change to a CS-capable RAT (including RAT, frequency, and cell information). As an option, the inter-RAT system information might be provided by the eNB 204 using the Network Assisted Cell Change (NACC) procedure for GERAN. In this case, the WTRU 202 receives in inter-RAT cell change order that may contain a CS fallback indicator, which indicates to the WTRU 202 that the cell change order was triggered due to a CS fallback request. If the inter-RAT cell change order contains a CS fallback indicator and the WTRU 202 fails to establish a connection to the target RAT, then the WTRU 202 considers that the CS fallback has failed.
If the WTRU 202 obtains the LA/RA information of the new UTRAN/GERAN cell (e.g., based on the system information or redirection information) and the LA/RA of the new cell is different from the one stored in the WTRU 202, it performs a LA Update or a Combined RA/LA update procedure if the target system operates in Network Mode of Operation (NMO) I (step 238). The WTRU 202 responds with a page response message to the MSC 210 as follows.
If the target RAT is UTRAN or GERAN Iu mode, the WTRU 202 establishes an RRC connection and responds to the paging message in an RRC Initial Direct Transfer message. The CN domain indicator is set to “CS” in the Initial Direct Transfer message. When received at the RNC 208, the Paging Response message is sent in an RANAP Initial WTRU message to the MSC 210 (step 242).
If the target RAT is GERAN A/Gb mode, the WTRU 202 establishes an RR connection by using the procedures specified in 3GPP TS 44.018 (i.e., the WTRU 202 requests and is assigned a dedicated channel, where it sends a Set Asynchronous Balanced Mode (SABM) containing a layer 3 Service Request message=PAGING RESPONSE to the BSS and the BSS responds by sending a UA). After establishing the main signaling link as described in 3GPP TS 44.018, the WTRU 202 enters either Dual Transfer Mode or Dedicated Mode and the CS call establishment procedure completes. When received at the BSC 208, the Paging Response message is sent in a BSSAP COMPLETE LAYER 3 INFORMATION message to the MSC. The BSS should be prepared to receive a PAGING RESPONSE even when a corresponding PAGING REQUEST has not been sent by this BSS. Also, the MSC 210 should be prepared to receive a paging response after a relatively long time from when the CS paging message was sent (step 226).
In case the MSC serving the 2G/3G cell is the same as the MSC that served the WTRU 202 while camped on LTE, it stops the paging response timer and establishes the CS connection (step 244).
If the MSC that receives the paging response is different from the MSC that sent the paging request and if the LA Update or Combined RA/LA Update was not performed, the MSC rejects the page response by releasing the A/Iu-cs connection (step 246). The RNC/BSC 208 in turn releases the RRC/RR connection (step 248). The RRC/RR release triggers the WTRU 202 to perform a LA Update (step 250) as follows. If the target system operates in Network Mode of Operation (NMO) I, then the WTRU 202 performs a combined RA/LA Update. When the target system operates in NMO I, if the WTRU 202 is still in UTRAN/GERAN after the CS voice call is terminated and if a combined RA/LA Update has not already been performed, the WTRU 202 performs a combined RA/LA Update procedure. This procedure is used to create a Gs association between the MSC/VLR 210 and the SGSN and to release the SGs association.
If the target system operates in NMO II or III, then the WTRU 202 performs a LA Update towards the MSC 210. The LA Update triggers the Roaming Retry for CS fallback procedure. When the target system operates in NMO II or III, if the WTRU 202 is still in UTRAN/GERAN after the CS voice call is terminated and if a LA Update has not already been performed, the WTRU 202 performs a LA Update procedure. This procedure is used to release the SGs association between the MSC/VLR 210 and the MME 206.
It is noted that if the WTRU is in Idle mode, then paging may be initiated, because the network is not aware of the location and attachment status of the WTRU. If the WTRU is in Connected mode, meaning that the WTRU is attached to the network, paging the WTRU is not needed and the network may easily reach the WTRU via a dedicated message. One example of a dedicated message is a “CS service notification” message.
FIG. 3 is a flow diagram of a method 300 for the preparation phase of a mobile originated (MO) call in active mode. In the method 300, messages are exchanged between a WTRU 302, an eNB 304, a BSS 306, an MME 308, an MSC 310, a SGSN 312, and a serving GW 314. The WTRU 302 sends a CS Call Request message to the eNB 304 (step 320). The eNB 304 may optionally request a measurement report from the WTRU 302 to determine the target GERAN/UTRAN cell to which PS handover will be performed (step 322).
When the WTRU 302 is moving, it may be necessary to handover the WTRU to a different eNB and/or BSS to maintain the connection between the WTRU and the network (i.e., perform a relocation process). The eNB 304 sends a Relocation Required message to the MME 308 (step 324). The MME 308 forwards a Relocation Request message to the SGSN 312 (step 326). The SGSN 312 sends a PS Handover Request message to the BSS 306 (step 328). The SGSN 312 reserves radio resources in a target BSS (step 330) and the target BSS creates a Target BSS to Source BSS Transparent Container (step 332). The BSS 306 sends a PS Handover Request Acknowledge message to the SGSN 312 (step 334). The SGSN 312 forwards a Relocation Response message to the MME 308 (step 336). After this step is completed, the WTRU 302 has been handed over to the target BSS.
FIG. 4 is a flow diagram of a method 400 for the execution phase of a MO call in active mode. In the method 400, messages are exchanged between a WTRU 402, an eNB 404, a BSS 406, an MME 408, an MSC 410, a SGSN 412, and a serving GW 414. Uplink and downlink payload PDUs are exchanged between the WTRU 402 and the eNB 404, utilizing the serving GW 414 as needed (step 420). The MME 408 sends a Relocation Command to the eNB 404 (step 422), which triggers the eNB 404 to send a Handover from E-UTRAN Command to the WTRU 402 (step 424).
The WTRU 402 and the eNB 404 perform a GERAN A/Gb access procedure (step 426) and the WTRU 402 sends an XID Response message to the BSS 406 (step 428). The BSS 406 sends a PS Handover Complete message to the SGSN 412 (step 430) and forwards the XID Response message to the SGSN 412 (step 432). Also at this time, it is possible for the WTRU 402 to send uplink packet data to the eNB 404 (step 434).
If the target RAT is GERAN, the WTRU 402 sends a SABM message with a Connection Management (CM) Service Request to the BSS 406 (step 436). The BSS 406 forwards complete Layer 3 information along with the CM Service Request to the MSC 410, which indicates that CS resources have been allocated in the GERAN cell (step 438). The BSS 406 responds to the WTRU 402 by sending a UA with the CM Service Request, which positively acknowledges the SABM message (step 440). The WTRU 402 then initiates a CS call establishment procedure (step 442).
Part of the processing of the Handover from E-UTRAN Command (step 424) includes the SGSN 412 receiving a Handover Complete message. Upon receiving the Handover Complete message, the SGSN 412 sends a Forward Relocation Complete message to the MME 408 to indicate completion of the PS handover procedure (step 444). The MME 408 responds to the SGSN 412 by sending a Forward Relocation Complete Acknowledge message to the SGSN 412 (step 446).
The SGSN 412 sends an Update PDP Context Request message to the serving GW, including a new SGSN address, a tunnel endpoint identifier (TEID), and a negotiated quality of service (QoS) (step 448) and optionally sends IP packets to the serving GW 414 (step 450). The serving GW 414 updates the PDP context fields and sends an Update PDP Context Response message (including the TEID) to the SGSN 412 (step 452). At this point, the serving GW 414 sends new incoming downlink IP packets to the SGSN 412 instead of the source eNB (step 454). The downlink IP packets are then forwarded to the BSS 406 (step 456) and ultimately to the WTRU 402 (step 458).
The WTRU 402 and the SGSN 412 perform an XID negotiation procedure for LLC ADM (step 460). The WTRU 402 and the SGSN 412 may also perform an XID negotiation procedure for LLC ABM (step 462). It is noted that one or both of the XID negotiation procedures (for ADM and ABM) may be performed, depending on the LLC layer parameters to be negotiated. The WTRU 402 triggers a routing area update procedure when it is possible to send uplink data packets (step 464).
Even with the foregoing procedures, there are two problems that need to be addressed: a combined location area update/tracking area update and the identity of the WTRU that is used for paging.
1. Combined Location Area Update/Tracking Area Update
One problem relates to the combined Location Area Update (LAU)/Tracking Area Update (TAU) procedure necessary to remain attached to the CS domain while in the E-UTRAN. In legacy GPRS, a routing area (RA) was a subset of a location area (LA). The system information would broadcast both the location area identity (LAI) and the routing area identity (RAI). A change in LA implied a change in RA, but not vice versa. In LTE System Information, there is no provision to broadcast the LA code of the surrounding legacy GSM/UMTS CS network. In addition, there is not supposed to be a pre-defined relationship between TAs and LAs. Therefore, this problem may be stated: how does the WTRU determine that a combined TAU/LAU procedure needs to be triggered?
2. WTRU Identity for Paging
A second problem relates to the WTRU identity for paging. In LTE, the WTRU identity for paging is the S Temporary Mobile Subscriber Identity (S-TMSI). But the WTRU is not supposed to respond to paging messages via the IMSI in LTE. In legacy GSM, the WTRU may be paged using either the TMSI or the IMSI.
In case the WTRU performed a combined EPS/IMSI Attach or a Combined TAU/LAU procedure, the MSC/VLR would either assign a TMSI to the WTRU or use the WTRU's IMSI for paging. A TMSI is unique only within the LA where it was assigned. Because there is no relationship between LAs and TAs, a WTRU may, in Idle Mode, cross LAs where the previously assigned TMSI may be invalid. FIG. 5 shows a conceivable scenario where the WTRU, while being in the same TA (TA1), crosses between two different LAs, such as LA1 and LA2, without performing a TA update procedure toward the MME. The problem in this situation is how to properly page the WTRU.
During the Attach procedure for connecting to LTE services (as shown in FIG. 1), the network must allocate an ID number to the WTRU (a Global Unique Temporary Identifier (GUTI) which includes the S-TMSI). All paging messages to the WTRU use the S-TMSI as the identifier for the WTRU. Under existing procedures, if the network pages the WTRU using the IMSI, the WTRU is supposed to detach from the network and then reattach to the network, to create the appropriate parameters in the network's database so that the WTRU may be paged using the IMSI. As one example, in GSM, the WTRU always has an IMSI and may also have a TMSI, if assigned by the network. But, the VLR does not have to allocate a TMSI to the WTRU. In LTE, the MME must allocate a GUTI, which includes the S-TMSI. If the VLR does not allocate a TMSI to the WTRU, and sends back the WTRU's IMSI in the Attach Accept message, then the WTRU must delete any TMSI that it had stored. As a result, the WTRU may only be paged by the IMSI. But if the WTRU may only be paged by the IMSI in the CS domain, there is a problem, because in LTE, the WTRU cannot be paged by the IMSI, and has to be paged by the S-TMSI.